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ABSTRACT 


The  Headquarters,  U.S  Forces  Command  (HQ  FORSCOM)  Decision  Support 
System(s)  (DSS)  Study  provides  planning  guidance  and  specific  recommendations  on 
how  DSS  can  be  implemented  at  HQ  FORSCOM.  This  study  includes  an  evaluation 
and  comparison  of  the  automation  environments  at  Headquarters  Department  of  the 
Army  (HQDA)  and  HQ  FORSCOM  and  specifically  discusses  how  the  FORSCOM 
Information  System  (FIS)  can  achieve  comparable  functionality  with  the  HQDA 
DSS. 


1.0  INTRODUCTION 


This  study  is  divided  into  two  main  areas:  a  description  of  the  current  situation  and 
a  plan  describing  recommendations  for  HQ  FORSCOM  DSS  implementation.  The 
situation  description  begins  with  general  descriptions  of  HQDA  and  HQ  FORSCOM 
followed  by  more  specific  comparisons.  The  systems,  environments  and  capabilities 
are  analyzed  and  serve  as  a  basis  for  generating  alternatives  and  recommendations. 
The  plan  portion  is  divided  into  three  sections:  a  near  term  plan,  a  FORSCOM 
unique  alternative  section  and  strategic  planning  guidance. 


1.1  GKNKKAL 

Georgia  Tech  Research  Institute  (GTRI)  was  tasked  by  FORSCOM  and  AIRMICS  to 
conduct  a  90  day  study  of  the  Headquarters  Department  of  the  Army  (HQDA)  and 
Headquarters  U.S.  Forces  Command  (HQ  FORSCOM)  data  automation  and  decision 
support  system  environments.  The  purpose  was  to  evaluate  the  existing  HQDA  DSS 
environment  for  applicability  to  HQ  FORSCOM  and  to  provide  recommendations  in 
the  form  of  a  plan  on  how  similar  capability  can  be  implemented  at  HQ  FORSCOM. 

The  study  included  a  visit  to  HQDA  to  investigate  the  hardware,  software,  database 
and  communications  capabilities.  Subsequent  to  this  visit,  GTRI  met  with  HQ 
FORSCOM  personnel  on  numerous  occasions.  The  functionality  of  the  FIS  was 
compared  with  that  known  to  exist  at  HQDA.  The  study  used  a  single  representative 
functional  area  as  a  focal  point  for  evaluation.  This  allowed  in-depth  analysis  so  that 
an  appropriate  level  of  detail  could  be  obtained  for  making  specific 
recommendations.  The  assumption  was  made  that  the  specific  information  gathered 
in  one  area  would  generate  planning  guidance  applicable  to  the  entire  headquarters. 

The  representative  functional  area  selected  was  the  budget  portion  of  the  FORSCOM 
J8  Directorate  of  Resource  Management.  This  area  was  selected  for  the  following 
reasons: 

a.  Data  supporting  the  FORSCOM  Automated  Program  and  Budget  System 
(FAPABS)  had  already  been  formatted  for  the  FORSCOM  Command 
Database. 


b.  HQDA  had  already  implemented  its  Budget  Management  Information 
System  (BMIS),  which  allowed  detailed  comparisons  of  capabilities. 

c.  The  capabilities  and  functionality  of  the  HQDA  DSS  were  recognized  by 
FORSCOM  J8  personnel  as  having  applicability  to  the  decision  process 
within  the  directorate. 

d.  The  FORSCOM  J8  fully  supported  the  project  and  was  willing  to  provide 
knowledgeable  personnel  to  assist  in  the  analysis. 

Deliverables  under  this  project  included  a  task  schedule,  work  plan  and  the 
FORSCOM  DSS  Study.  HQ  FORSCOM  also  requested  a  draft  copy  of  the  study  for 
review  and  comment.  A  formal  presentation  on  the  findings  and  recommendations 
in  addition  to  the  deliverables,  was  also  requested. 
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2.0  SITUATION 


2.1  HQDASmJATION 

The  headquarters  of  the  Department  of  the  Army  (HQDA)  has  developed  decision 
support  system  capabilities  used  throughout  the  DA  staff  to  aid  the  decision  process, 
depict  activities,  and  provide  recommendations.  The  system  is  characterized  by  its 
current  capability,  the  DSS  development  environment,  and  a  continually  evolving 
DSS  capability.  These  three  characteristics  are  described  in  the  following 
paragraphs. 

2.1.1  Current  Capability 

The  current  capabilities  of  the  HQDA  DSS  include  the  ability  to  evaluate  data,  and 
construct  graphs  and  charts.  This  capability  is  used  to  depict  interrelationships  and 
trends.  This  DSS  is  a  valuable  tool  for  action  officers  in  their  preparation  of  briefings 
and  reports.  Other  capabilities  include  a  mail  box,  calendar  and  other  features  of  the 
professional  office  system  (PROFS). 

2.1.2  DSS  Development  Environment 

One  key  to  the  success  of  the  HQDA  DSS  is  the  environment  in  which  the  system 
exists,  is  maintained,  and  within  which  new  applications  are  developed.  The  DA 
system  environment  has  evolved.over  time.  What  began  as  a  database  manipulation 
and  query  system  for  DCSPER  (Project  FORECAST)  has  grown  into  the  current 
development  environment.  This  did  not  occur  overnight  and  was  the  result  of  the 
direction  and  support  from  the  highest  levels  within  HQDA. 

Substantial  changes  were  made  in  the  organizational  focus  at  HQDA.  Some 
reorganization  occurred  subsequent  to  the  Vice  Chief  of  Staff  of  the  Army  (YCSA) 
initiative  in  1985.  One  initiative  was  to  improve  information  management  and 
decision  system  support  throughout  the  headquarters.  This  established  Decision 
System  Management  Offices  (DSMOs)  in  each  Army  Staff  Agency  to  complement 
their  existing  Information  Management  Officer.  The  U.S  Army  Decision  Systems 
Management  Agency  (DSMA)  was  formed  in  1986  using  resources  from  the 
FORECAST  office  to  provide  a  Decision  System  Management  Office  at  OCSA  level. 


DSMA  changed  from  the  role  of  developer  to  the  role  of  integrator  and  keeper  of  the 
environment.  Functions  under  the  commander  DSMA  include: 

•  Computer  operations 

•  Training 

•  Database  Administration 

•  Systems  Engineering 

•  Systems  Security 

•  Applications  Software  Management 

•  Plans  and  Architecture 

DSMA  provides  the  support  environment  used  by  the  DSMOs  under  each  Deputy 
Chief  of  Staff.  The  DSMOs  are  in  turn  responsible  for  the  planning  and  execution  of 
the  specific  applications  packages.  Some  of  the  functions  under  the  DSMO  cells 
include: 

•  Develop  general  and  specific  plans  for  their  functional  area. 

•  Applications  Software  and  DSS  Development 

•  Contract  Monitoring 

•  System  Maintenance 

•  Applications  Software  Training 

Each  DSMO  establishes  requirements  and  is  responsible  for  every  aspect  of  an 
application  including  documentation,  upgrades,  and  life  cycle  management.  When  a 
new  software  application  is  implemented,  it  is  developed  according  to  standards, 
guidelines,  and  procedures  set  by  DSMA. 

The  HQDA  environment  can  also  be  described  in  the  following  manner: 

•  Mature  Environment.  The  system  origins  can  be  traced  back  over  12 
years  and  reflect  many  lessons  learned  over  time. 

•  Well  Staffed.  The  DSMA  has  over  13  persons  assigned  full  time.  The 
DSMO  at  ODCSLOG  has  9  military  and  civilian  slots.  These  numbers  do 
not  reflect  the  contractor  support. 


•  Well  Funded.  According  to  the  "Vision"  briefing,  (see  reference  5) 
between  $45  and  $50  million  has  been  spent  for  software  development 
over  the  last  12  years.  DSMO  at  ODCSLOG  is  budgeted  at  approximately 
$2.5  million  per  year  in  accord  with  the  DSMA  master  plan. 

•  Well  Documented.  Both  planning  and  execution  guidance  are  well 
documented  and  updated  regularly. 

•  Well  Supported.  The  HQDA  DSS  program  is  supported  by  the  VCSA  and 
other  senior  leadership  in  the  Pentagon. 


2.1.3  Evolving  DSS  Capability 

The  capabilities  within  HQDA  for  decision  support  are  not  limited  to  the  database 
retrieval  and  graphic  display  capabilities  mentioned  in  section  2.1.1.  The  HQDA 
plan  provides  for  future  implementation  of  emerging  capabilities  and  technologies  in 
light  of  the  Army’s  mission.  HQDA  recognizes  that  this  system  (consisting  of  PL/1, 
Data  Management  System,  and  Virtual  Machine  Operating  System)  does  not 
provide  for  capturing  the  power  of  personal  computers.  The  HQDA  plan  is  time- 
phased  to  allow  the  incorporation  of  programming  and  database  access  languages 
which  will  enable  mainframe  applications  to  be  moved  to  mini  computers  and  PCs. 
The  HQDA  plan  has  a  strategic  focus  and  is  revised  as  requirements  and  technology 
change. 

Current  DSMA  and  ODCSLOG  plans  call  for  future  implementation  of  distributed 
databases,  transportable  software,  and  enhanced  interfaces  for  ease  of  use.  Their 
plan  also  considers  ease  of  training,  and  the  application  of  technologies  such  as 
Artificial  Intelligence  to  their  missions. 


2.2  HQ  FORSCOM  SITUATION 


The  Headquarters  U.S.  Forces  Command  has  developed  the  FORSCOM  Information 
System  (FIS)  which,  along  with  the  databases  on  the  installation  mainframe, 
provides  the  basic  environment  to  meet  the  current  and  emerging  needs  for 
information  management.  The  concept,  as  stated  in  the  J6  FIS  briefing,  is  as  follows: 

"The  FIS  concept  is  a  total  integration  of  text  processing,  time 
management,  document  distribution,  formal  and  informal  electronic 
mail,  graphics,  spreadsheet,  interactive  data  processing,  and  access  to 
systems  such  as  ASIMS,  DDN,  and  other  standard  Army  systems 
provided  by  the  Information  Systems  Command.” 

The  FIS  can  be  characterized  in  terms  of  its  current  capability  and  its  potential  for 
implementation  of  DSS. 

2.2.1.  Current  Capability 

The  current  capabilities  of  the  HQ  FORSCOM  environment  include  the  ability  to 
retrieve  data  files  fiom  a  command  database  (over  separate  classified  and 
unclassified  networks),  plus  a  set  of  commercial  packages  to  provide  word 
processing,  spreadsheet  analysis,  graphics  and  database  manipulation.  These 
packages  are  accessed  through  a  system  menu  that  also  links  to  the  PROFS  system. 

From  a  DSS  perspective  the  FIS  is  a  system  in  an  early  stage  of  growth  and  is  several 
years  away  from  reaching  its  potential  to  aid  the  FORSCOM  action  officers  and 
senior  decision  makers  in  meeting  the  command  mission  objectives.  It  is  currently 
estimated  by  FORSCOM  that  full  implementation  of  the  Command  Data  Base  alone 
will  take  five  years.  Although  many  pieces  of  the  system  will  not  be  completed  for 
some  time,  a  basic  foundation  exists  upon  which  Decision  Support  Systems  can  be 
implemented. 

2.2.2  Growth  Potential 

HQ  FORSCOM  has  its  own  information  management  goals  and  vision  for  the  future. 
Some  of  these  are  expressed  as  requirements  in  the  J6  FIS  briefing  as  follows: 
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•  Office  information  sharing 

•  Document  processing 

•  Information  transfer 

•  Terminal  for  each  work  station 

•  Decision  support  software 

•  Administrative  support 

•  Modular/future  growth 

•  Data  access  and  development 

•  Security 

•  Database  access 

•  Query/report  generation 

•  Total  protocol  compatibility 

•  Friendly  language 

•  Least  disruptive 

•  Full  support 

•  Maintenance 

•  Education  and  training 

•  Documentation 

•  Highly  reliable 

HQ  FORSCOM  has  a  vision  of  the  future  and  a  system  concept  that  includes  a  well 
defined  database  concept.  Detailed  plans  and  preparations  for  the  implementation  of 
the  Command  Data  Base  are  being  executed.  Other  initiatives  are  underway  to 
implement  DSS  and  other  utilities  to  assist  end  users  in  their  jobs. 


2.2.3  Unique  FORSCOM  Characteristics 

FORSCOM  has  subordinate  organizational  relationships  and  situations  that  have  no 
direct  counterpart  at  HQDA.  These  are  the  Continental  U.S.  Armies  (CONUSAs) 
and  the  FORSCOM  installations.  Also,  HQ  FORSCOM  operates  on  numerous 
systems  in  contrast  to  HQDA’s  primary  single  system.  The  characteristics  of  the 
CONUSAs.  installations,  and  mainframe/workstation  utilization  are  discussed 
separately  in  the  following  paragraphs. 


2.2.3. 1  CONUSA  Characteristics 


Each  CONUSA  HQ  has  a  Wang  VS100  running  the  VS  operating  system. 
FORSCOM  also  possesses  a  Wang  VS100  that  interfaces  with  the  CONUSAs.  The 
Wang  systems  are  independent  of  FIS  and  the  installation  host  systems. 

Since  all  CONUSA  computer  systems  have  the  same  general  configuration,  any 
software  developed  for  a  CONUSA  (or  FORSCOM  Wang  system)  can  be  physically 
transferred  to  others  easily,  without  significant  modification.  Software  developed 
for  the  IBM  systems  of  the  FIS  would  require  significant  modification  to  run  on  the 
CONUSA  Wang  systems.  The  cost/benefit  of  porting  such  applications  from  the  FIS 
to  the  CONUSA  would  have  to  be  determined  on  an  application-by-application  basis. 

If  the  application  is  deemed  suitable,  other  considerations  must  be  examined. 
Porting  of  any  general  application  available  to  HQ  FORSCOM  to  each  CONUSA 
must  first  be  in  compliance  with  restrictions  placed  on  all  reserve  components  of  the 
CONUSA.  The  program  manager  for  the  Reserve  Component  Automation  System 
(RCAS)  has  dictated  that  no  hardware,  software,  or  communications  capability  is  to 
be  added  to  the  RCAS  system.  RCAS  is  currently  scheduled  for  fielding  in  the  early 
1990s.  Automation  support  to  the  CONUSAs  would  be  constrained  to  only  the  active 
components  and  not  to  the  Major  U.S.  Army  Reserve  Components  (MUSARC). 

2. 2.3.2  Installation  Characteristics 

Installations  generally  have  an  IBM  43xx  series  system  to  interface  with  the  ASIMS 
(VIABLE)  system  and  an  IBM  43xx  series  system  to  provide  host  functions  (similar 
to  those  performed  by  the  host  processor  at  HQ  FORSCOM).  Currently,  the 
installations  use  an  assortment  of  operating  systems,  including  MVS,  VM,  and 
DOS/VSE.  General  software  functions  such  as  databases  also  vary  from  installation 
to  installation.  In  addition,  the  usage  of  PCs  as  terminals  varies  widely. 

Users  at  the  installation  level  can  interface  with  other  installations  via  ASIMS.  FIS 
users  can  also  interface  with  the  installations  using  ASIMS  and  the  distributed 
processors.  Data  can  be  acquired  from  ASIMS,  reworked  locally  and  then  stored  on 
the  host  system  (or  vice  versa ),  at  both  the  installations  and  HQ  FORSCOM. 
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2. 2.3.3  Mainframe/Workstation  Utilization 


The  FIS  was  designed  to  provide  office  automation  and  services  for  decision  makers, 
action  officers  and  secretaries.  Personal  computers  are  utilized  as  user  workstations 
allowing  the  accomplishment  of  many  tasks  locally,  without  requiring  the  use  of 
other  systems.  The  host  mainframe  provides  access  to  the  CDB.  Users  can  download 
data  to  the  workstation  and  manipulate  it  off-line,  although  data  queries  can  be 
performed  on  the  mainframe  with  the  workstation  acting  as  a  dumb  terminal. 


2.3  SITUATION  COM  PA  RISON  -  HQDA  DSS  and  HQ  FORSCOM  FIS 


2.3.1  Hardware  Situation 

The  hardware  situation  comparison  is  divided  into  three  parts:  host  processor, 
distributed  processor  and  workstation.  The  operating  systems  and  network 
configuration  are  discussed  in  this  section  since  they  relate  more  to  hardware 
function  and  performance  than  to  user  applications. 

2.3. 1.1  Host  Processor 

This  section  provides  a  brief  description  of  the  HQDA  DSS  host  processor  system  as 
contrasted  to  the  HQ  FORSCOM  host  processor  system.  Basically,  there  is  little 
difference  between  these  systems.  Both  HQDA  and  HQ  FORSCOM  use  the  IBM 
30xx  series  mainframe  computers  as  their  host  system.  HQDA  uses  its  host  for  all 
mainframe  user  functions  (such  as  the  DSS),  while  FORSCOM  utilizes  its  host  as  a 
hub  to  connect  to  distributed  processors  and  to  perform  some  mainframe  user 
functions  (such  as  the  Command  Data  Base). 

The  operating  systems  used  by  the  host  systems  at  HQDA  and  FORSCOM  ore 
different;  HQDA  DSS  uses  the  VM  operating  system,  while  HQ  FORSCOM  uses  the 
MVS  operating  system.  These  operating  systems  provide  similar  functions  through 
different  methods.  Therefore,  there  is  no  real  difference  in  what  the  user  can 
potentially  perform. 

Action  officers  and  senior  decision  makers  interviewed  at  FORSCOM  expressed  a 
desire  to  view  data  that  HQDA  is  using  to  make  decisions  directly  affecting 
FORSCOM.  The  ability  to  update  this  data,  or  at  least  request  changes,  would  be  an 
added  benefit.  As  of  14  October  1988.  there  were  72  FORSCOM  users  on  the  HQDA 
DSS.  These  users  appear  to  use  their  system  privileges  primarily  for  electronic  mail. 

The  capability  to  access  the  HQDA  DSS  system  already  exists  on  the  FIS.  The  FIS 
user  accesses  the  HQDA  DSS  through  the  AMSNET/FORECAST  subsystem  of  the 
External  Systems  item  on  the  main  FIS  menu  (the  FIS  user  can  also  gain  access  via 
the  modem  pool).  Unfortunately,  the  current  configuration  of  the  network  excludes 
the  use  of  graphics  transmitted  from  the  HQDA  DSS.  Some  of  the  HQDA  database 
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applications  require  graphics  capabilities  to  view  data.  Since  the  graphics 
capabilities  are  one  of  the  major  strong  points  of  the  HQDA  DSS,  the  lack  of  graphics 
minimizes  the  usefulness  of  the  DA  DSS  from  a  KIS  workstation. 

The  HQDA  host  processor  has  been  carefully  configured  to  optimally  fulfill  DA 
needs.  New  system  functions  and  applications  are  added  based  on  established 
procedures  to  provide  the  best  performance.  The  host  processor  at  FORSCOM  has 
not  been  configured  this  way.  New  system  functions  and  applications  are  added 
without  regard  to  system  performance.  As  a  result,  the  system  cannot  easily  support 
new  functions  under  the  current  configuration.  System  throughput  does  not  conform 
to  the  machine  potential.  The  primary  reason  for  this  is  the  lack  of  fine-tuning  of  the 
host  processor. 

2.3. 1.2  Distributed  Processors 

HQ  FORSCOM  makes  use  of  a  number  of  different  distributed  processors;  something 
HQDA  cannot  do.  In  the  sense  of  the  FIS,  the  HQDA  host  system  could  be  viewed  as 
being  both  the  host  processor  and  distributed  processor.  From  that  perspective,  HQ 
FORSCOM  has  a  large  functional  advantage.  HQDA  has  one  system  to  provide 
mainframe  database  access,  electronic  mail  and  other  support  functions.  HQ 
FORSCOM  is  able  to  distribute  this  workload,  providing  a  more  robust  system. 
When  the  HQDA  system  goes  down  all  users  must  wait  until  the  system  comes  back 
on  line.  With  the  multiple  systems  at  FORSCOM,  if  a  distributed  processor  goes 
down  other  systems  are  still  on  line.  This  allows  other  users  to  continue  work  on 
systems  that  are  not  effected. 

Multiple  systems  allow  the  use  of  multiple  operating  systems.  HQ  FORSCOM 
currently  runs  three  operating  systems  on  the  host  and  distributed  processors:  VM, 
MVS  and  DOS/VSE.  These  provide  the  ability  to  run  virtually  any  mainframe 
software  package.  In  contrast,  the  entire  HQDA  system  runs  under  the  VM 
operating  system. 

2.3. 1.3  Workstations 

Both  HQDA  and  HQ  FORSCOM  make  use  of  personal  computers  as  the  primary 
user  workstation.  This  provides  users  with  the  computational  power  to  perform 
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many  functions  locally  without  burdening  the  mainframe  systems.  The  use  of  PCs 
allows  the  user  to  continue  to  solve  problems  even  when  the  link  to  the  host  system  is 
unavailable.  In  addition,  users  can  perform  many  office  tasks,  such  as  word 
processing,  spreadsheets,  and  generation  of  briefing  materials,  with  nothing  more 
than  the  system  on  their  desk.  The  main  difference  between  the  HQDA  and  HQ 
FORSCOM  local  processors  is  the  use  of  a  fixed  hard  disk  at  HQDA  as  opposed  to  the 
removable  disk  pack  at  HQ  FORSCOM.  Both  locations  use  the  DOS  operating 
system. 


2.3.2  Software  Situation 

This  section  describes  the  software  situation  at  HQDA  and  HQ  FORSCOM, 
including  system  utilities  and  user  applications.  This  section  is  divided  into  host 
processor,  distributed  processor,  and  workstation  software.  There  is  some  overlap 
due  to  differences  in  configuration  between  HQDA  and  HQ  FORSCOM  systems. 

2.3.2.1  Host  Processor 

Many  HQDA  DSS  applications  integrate  graphics  with  database  information.  This 
graphics  capability  is  provided  by  the  Graphical  Data  Display  Manager  (GDDM) 
utility  on  the  host  processor.  Each  application  handles  its  own  graphics  using 
GDDM,  based  on  DSMA-defined  interface  standards.  HQ  FORSCOM  does  not  use 
graphics  in  conjuction  with  database  information.  GDDM  is  installed  on  the  IBM 
4361  distributed  processor  running  the  DOS/VSE  operating  system.  There  is  a 
graphics  display  manager  enhancement  with  the  FORTRAN  compiler  on  the  host 
processor,  but  it  is  not  currently  used  with  the  database. 

HQDA  has  implemented  most  of  their  existing  software  using  the  PL/1 
programming  language.  However,  Cross  System  Product  (CSP)  will  be  used  for  all 
new  software.  HQ  FORSCOM  has  software  written  in  COBOL,  FORTRAN, 
ROSCOE  and  SLAM  II  on  the  host  processor. 
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2.3.2. 2  Distributed  Processors 


HQDA  does  not  use  distributed  processors.  Access  to  the  HQ  FORSCOM  distributed 
processor  software  is  provided  automatically  through  the  FIS  menu  structure.  The 
FIS  distributed  processors  have  a  number  of  tools  comparable  to  those  on  the  HQDA 
DSS  host.  HQDA  uses  PROFS  for  electronic  mail  and  data  communication,  as  does 
HQ  FORSCOM.  CSP  is  implemented  on  the  FIS  4361  distributed  processor.  This 
processor  is  used  for  installation  tasks  and  is  separate  from  the  CDB.  This 
distributed  processor  also  has  GDDM,  although  applications  using  these  tools  do  not 
appear  to  be  in  general  use  as  they  are  at  HQDA. 

2.3. 2.3  Workstations 

Both  HQDA  DSS  and  the  FIS  utilize  menus  extensively.  HQDA  implements  the 
menu  system  on  the  mainframe  while  HQ  FORSCOM  uses  the  workstation.  HQDA 
does  not  include  any  PC  functions  in  the  menu.  Both  locations  use  dBase  III 
extensively  for  local  processing  of  database  information.  HQDA  allows  the  use  of  a 
command  line  to  go  directly  to  an  application,  without  the  use  of  menus.  They  have 
also  standardized  the  user  interface  to  be  used  for  all  applications.  This  ensures  that 
tasks  (such  as  data  transfer,  printing,  exiting  the  program,  etc.)  are  accomplished 
identically  in  all  applications. 

HQDA  DSS  utilizes  a  jump  key  to  allow  the  user  to  switch  between  mainframe  and 
PC  tasks.  This  allows  the  user  to  initiate  a  task  on  the  host  system  and  jump  to  the 
PC  session  while  the  task  completes.  The  FIS  does  not  have  this  switch  capability. 


2.3.3  Database  Situation 
2.3.3. 1  HQDA  DSS 

From  a  database  standpoint,  HQDA  DSS  is  well-structured.  Within  DSMA  there 
are  database  administrators,  an  integrated  database  team,  data  administrators  and 
a  database  coordinator  for  each  project.  Each  has  specific  responsibilities  and 
functions. 


SQL/DS  is  the  standard  DBMS  (Data  Base  Management  System).  Data  is  primarily 
accessed  through  applications  selected  from  menus.  Within  an  application,  the  user 
generally  has  three  options  for  viewing  and  extracting  data:  menus,  SQL  queries 
and  Intellect.  The  simplest  to  use  is  the  menu  approach.  The  "menus”  are 
contractor  developed  software  packages  that  embed  text  and  graphics  for  ease  of 
access  to  frequently  requested  data  in  a  pre-defined  format.  Training  time  to  use  the 
menu  options  is  mimimal.  SQL  queries  and  Intellect,  on  the  other  hand,  are  used 
when  the  user  desires  a  format  not  provided  by  the  menus.  Both  allow  command  line 
input  for  data  queries.  SQL  is  a  technical  computer  language  for  experienced  users. 
Intellect  is  a  natural  language  interface  developed  by  the  Artificial  Intelligence 
Corporation.  Intellect  allows  the  user  to  access  data  using  common  English  words. 
This  method  of  data  query  is  fairly  simple  to  learn  and  easy  to  use.  Intellect  also  has 
built-in  graphics  and  printout  support.  Thus,  users  may  extract,  print  and 
graphically  display  data  from  within  one  integrated  package. 

2. 3.3. 2  HQ  KOKSCOM 

The  FORSCOM  Information  System  (FIS)  handles  large  amounts  of  data  which  are 
stored  in  multiple  files.  These  files  are  being  evaluated  and  combined  into  several 
large  files.  The  goal  is  to  refine  the  data  elements  so  that  there  will  ultimately  be 
one  data  source,  the  Command  Data  Base  (CDB).  This  process  is  defined  and 
constrained  by  the  Information  Architecture  Model  (LAM)  which  provides  a  means  of 
mapping  the  relationship  between  every  element  of  the  FIS.  The  IAM  is  a  powerful 
planning  tool. 

The  FIS  currently  has  multiple  software  packages  for  data  querying  and  extraction. 
These  include  Datacom,  Data  Query  and  Data  Reporter,  which  are  products  of 
Applied  Data  Research,  Inc.  (ADR).  In  general,  these  programs  allow  users  to  create 
and  process  queries  and  then  view  the  results  either  onscreen  or  as  a  printout.  Most 
of  the  data  resides  or  originates  at  the  mainframe  level. 

At  the  PC  level,  the  FIS  provides  the  user  with  LOTUS  1-2-3  (product  of  Lotus  C<>rpL 
dBase  III  Plus  (product  of  Ashton-Tate)  and  Microsoft  Windows  (product  of 
Microsoft).  Graphics  support  is  primarily  obtained  from  Windows  and  LO  l  US. 
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Users  can  import  extracted  data  into  these  programs  and  manipulate  it  further  as 
charts  and  graphs  if  necessary. 

2.3.3.3  Comparative  Example  -  Database  Situation 

To  illustrate  how  similar  functions  can  be  performed  using  the  current  HQDA  and 
FIS  systems,  a  comparative  example  is  given.  Figure  2.1  diagrams  the  steps  a  user 
would  take  on  each  system  when  their  objective  is  to  produce  a  report,  complete  with 
graphics.  On  the  HQDA  DSS,  the  user  has  the  ability  to  go  directly  from  the  initial 
menu  to  a  specific  application  such  as  BMIS.  After  two  additional  menu  selections, 
the  user  may  execute  data  queries,  display  graphics  and  print  hard  copies. 

There  are  no  graphics  capabilities  embedded  within  or  accessible  from  the  data 
extraction  software  on  the  FIS.  Therefore,  the  procedure  for  accessing  graphics  has 
more  steps.  To  attain  graphics,  the  user  must  download  data  from  the  mainframe  to 
their  PC  and  then  pull  the  data  into  Lotus,  Windows  or  some  other  graphics  package. 
To  download  data,  the  user  must  go  through  four  menu  levels  before  specifying  a 
data  file  and  extracting  data.  Then,  the  user  must  back  out  of  PC  Datacom  and 
access  the  graphics  software.  In  addition,  the  user  often  uses  dBase  III  to  format 
and/or  manipulate  the  data  prior  to  producing  the  graphics.  Overall,  the  FIS  user 
has  to  go  through  many  more  steps. 

In  general,  similar  final  products  can  be  produced  from  either  system.  On  the  FIS 
however,  the  procedure  is  more  complicated,  time  consuming  and  requires  more 
training.  This  is  largely  because  utilities  which  provide  data  extraction  and 
graphics  are  accessed  as  separate  entities.  The  user  must  become  familiar  not  only 
with  the  operation  of  each  utility  but  also  with  how  to  get  to  them  from  a  system 
menu  or  from  within  another  utility. 

The  FIS  can  perform  database  functions  but  needs  enhancements  to  achieve  HQDA 
functionality.  The  FIS  allows  data  access  from  the  CDB,  but  has  little  of  the  ease  of 
use  of  the  DA  system.  HQ  FORSCOM  does  not  have  similar  functionality  with  the 
DA  system  in  the  following  areas  :  menu  queries  with  embedded  modules  for  text  or 
graphics  output,  the  ability  to  access  data  through  a  structured  query  language  from 
a  command  line  rather  than  through  a  menu  scheme,  and  the  ability  to  request  data 
in  the  form  of  text  or  graphics  using  a  natural  language  interface. 
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2.3.4  Training 


Both  HQDA  and  HQ  FORSCOM  provide  training  courses  for  their  users.  As  is 
shown  in  the  list  below,  HQDA  users  spend  less  time  in  trainings.  They  are  given 
introductory  level  training  in  one  and  a  half  days.  In  contrast,  FIS  users  spend  a 
total  of  Five  days  (ten  half  days)  learning  the  basics. 


HQDA 

Introductory 

Advanced 

Specific  Application 


1.5  days  (action  officers) 

0.5  days  (executive  officers) 

0.5  days  (average) 

1-3  days  depending  on  the  applic  ation 


HQ  FORSCOM 

Application  A  (Profs,  Multimate,  Printing)  2.5  days 
Application  B  (Lotus,  dBase)  2.5  days 

Data  Transfer  (PC  Datacom)  2.5  days 

Advanced  Graphics  &  Spreadsheet  5.0  days 

ADR  DatacomDB  4.0  days 


(5  x  0.5ea) 
(5  x  0.5ea) 
(5  x  0.5ea) 

( 10  x  0.5ea) 
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3.0  HQ  KORSCOM  DSS  PLAN 


The  following  HQ  FORSCOM  DSS  Plan  has  two  components:  a  specific,  near  term 
plan  to  enhance  functionality  in  the  current  FIS  structure,  and  strategic  planning 
guidance  to  focus  on  HQ  FORSCOM  DSS  planning  for  the  future.  Both  the  near 
term  plan  and  the  strategic  planning  guidance  reference  comparable  capabilities  at 
HQDA.  Section  3.2  addresses  concerns  that  are  unique  to  FORSCOM. 


3.1  NEARTERM  KORSCOM  DSS  PLAN 

The  near  term  plan  consists  of  objectives,  alternatives,  recommendations  and 
implementation  guidelines.  Based  upon  the  objectives,  alternatives  and 
recommendations  were  selected.  Guidelines  are  given  for  implementation  of  the 
recommendations  which  will  enable  FIS  to  e  hieve  the  basic  functionality  of  HQDA 
DSS. 

3.1.1  Near  Term  Objectives 

The  near  term  objectives  for  the  FORSCOM  DSS  are  derived  from  three  sources: 

1.  The  implied  objectives  in  the  FORSCOM  DSS  Statement  of  Work. 

2.  The  comparison  between  the  FIS  and  the  HQDA  DSS  functionalities. 

3.  The  necessity  for  creating  a  DSS  environment  foundation  at  least 
functionally  comparable  to  the  HQDA  DSS. 

All  of  the  objectives  are  directly  related  to  improving  the  job  performance  of  the 
typical  HQ  FORSCOM  action  officer.  The  objectives  taken  together  will  provide  a 
solid  foundation  for  creating  a  DSS  environment.  They  also  establish  the  general 
framework  for  the  FIS's  comparable  functionality  vis-a-vis  the  HQDA  DSS.  The 
below  stated  objectives  are  not  constrained  by  current  technology  or  particular 
idiosyncracies  of  the  HQ  FORSCOM  environment.  They  track  solely  on  the 
perceived  needs  of  the  FIS  user. 
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The  near  term  objectives  for  the  FORSCOM  DSS  fall  into  three  general  areas  with 

respect  to  the  user:  Speed,  Ease,  and  Effectiveness. 

Speed  objectives: 

1.  The  rapid  display  of  decision  information  on  activity  status,  trends  and 
interrelationships  in  data  or  graphic  form. 

2.  Significantly  faster  automated  preparation— as  compared  with  manual 
methods— of  recommendations,  reports,  briefings  and  slides. 

3.  Information  transferred  within  seconds  among  user  work  stations  or 
between  the  user  and  the  FIS. 

4.  User  receives  adequate  training  for  general  system  operation  in  two  days. 

Ease  objectives: 

1.  Task  requests  are  intuitive  with  simple  human  initiation  and  minimal 
human-to  machine  interaction. 

2.  Human-to-machine  interactions  occur  up-front  with  time-intensive 
processes  not  tying  up  the  user. 

3.  Movement  between  applications  and  transfer  of  data  is  simple,  intuitive 
and  transparent. 

4.  System  user  interfaces  are  consistent,  intuitive  and  simple  enough  to 
promote  progressive  independent  learning. 

Effectiveness  objectives: 

1  Outputs  focus  on  decision  assistance  for  decision  makers:  slides, 
briefings,  charts,  correspondence,  and  messages. 

2.  Information  is  easily  transferred  between  users,  and  between  user  and 
the  FIS. 

3.  Different  types  of  information  (ie.,  words,  graphs,  spreadsheets)  are 
readily  merged  and  blended  in  any  output  medium. 

4.  Training  focuses  on  specific  action  officer  tasks. 
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3.1.2  Alternatives  for  Comparable  Functionality 


The  alternative  recommendations  listed  below  are  designed  to  facilitate  the  near 
term  objectives.  They  establish  an  environment  which  will  support  future  DSS 
modules  such  as  the  J8's  future  FAPABS  upgrade.  These  recommendations  also 
pave  the  way  for  achieving  and  possibly  surpassing  comparable  functionality  with 
the  HQDA  DSS. 

The  alternative  recommendations  are  divided  into  the  major  categories  of  hardware, 
software,  and  training.  The  hardware  and  software  categories  are  further  organized 
along  the  lines  of  the  three  tier  architecture  when  applicable.  This  organization 
meshes  smoothly  with  the  FIS's  physical  organization  of  mainframe,  distributed 
processors,  and  personal  microcomputers. 

3. 1.2.1  Recommended  Hardware  Alternatives 

MAINFRAME: 

1)  Baseline  and  fine-tune  the  DOIM  IBM  4381  mainframe  host  processor. 
Fine-tuning  would  enhance  the  performance  of  the  host  processor 
without  the  addition  of  new  hardware  or  software.  The  HQ  FORSCOM 
host  processor  does  not  perform  up  to  the  machine's  capabilities.  The 
performance  gains  in  such  areas  as  throughput.  Central  Processing  Unit 
(CPU)  utilization,  and  user  response  time  should  be  significant.  System 
administrators  should  be  able  to  perform  this  baselining  and  fine-tuning 
as  part  of  their  normal  function.  Establishing  a  baseline  is  a  prerequisite 
to  identifying  any  other  bottlenecks  in  the  system. 

2)  Upgrade  existing  data  link  from  the  FIS  to  the  HQDA  DSS.  This  would 
allow  easier  access  to  DA  data  and  provide  a  potential  graphics  capability 
for  FIS  terminals  viewing  HQDA  DSS  data.  The  upgrading  of  the 
network  connection  would  expand  the  network’s  power,  speed  and 
electronic  mail  functionality.  A  FIS  user  must  have  an  inexpensive 
software  utility,  such  as  PC-Link,  to  access  the  HQDA  DSS  graphics.  No 
other  hardware  or  software  changes  would  be  necessary.  FIS  users  could 
then  access  HQDA  DSS  graphics  as  if  they  were  HQDA  users.  Personnel 
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at  HQDA  have  already  been  in  contact  with  Boeing  engineers  about  the 
feasibility  of  upgrading  the  network  connection.  They  have  been  assured 
that  Boeing  has  all  the  hardware,  software  and  expertise  to  perform  this 
upgrade. 

3)  Increase  the  number  of  phone  lines  into  HQDA’s  TAPNET  System  for  use 
by  HQ  FORSCOM.  Currently  this  system  has  only  four  phone  lines  for 
outside  users’  use.  Currently  all  of  these  lines  are  being  used.  HQ 
FORSCOM  can  add  more  lines  for  its  use  but  it  must  fund  them.  Having 
these  lines  would  enable  graphics  to  be  displayed  along  with  the  presently 
available  menus  and  data.  This  would  still  require  the  use  of  a  utility 
similar  to  PC-Link. 

LOCAL  WORKSTATION  (PC): 

A  memory  expansion  card  may  be  required  to  support  possible  software 
upgrades.  This  should  not  preclude  other  potential  hardware  upgrades  as 
the  interface  evolves,  i.e.  pointer  devices,  voice  recognition  and  optical 
scanners. 


3.1.2.2  Recommended  Software  Alternatives 
MAINFRAME: 

1)  Integrate/embed  graphics  capabilities  into  the  data  extraction  software 
on  the  mainframe.  Currently  users  must  transfer  data  into  a  separate 
program  on  their  PC  to  generate  graphic  displays.  Embedded  graphics 
could  be  accessed  more  quickly. 

2)  Acquire/develop  a  natural  language  interface  for  data  extraction.  The 
current  ADR  products  (Dataquery,  Datareporter  and  PC  Datacom)  exist 
as  separate  entities.  A  natural  language  interface  tying  these  together 
would  simplify  data  querying  for  the  user.  It  would  reduce  the  number  of 
layers  a  user  must  traverse  to  get  to  the  point  where  a  query  cun  be 
created  or  executed.  A  natural  language  interface  allows  the  user  to 
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phrase  queries  in  plain  English.  This  is  not  only  easier  to  use  but  also 
requires  less  training. 


PC: 

1)  Enhance  Sessions  Manager  screens  to  decrease  steps  required  to  perform 
functions.  Functions  should  also  be  grouped  logically,  and  enable 
potential  technological  upgrades  such  as  pointer  devices.  This  can  be 
facilitated  by  utilizing  a  human  factors  expert  to  analyze  the  human- 
computer  interface. 

2)  Expand  PC  Datacom  to  include  additional  data  retrieval  and  display 
functions.  Such  functions  would  include:  grouping  data  from  the 
mainframe  and  PC  and  displaying  this  data  in  graphical  form.  The 
transfer  of  data  from  mainframe  to/from  PC  should  be  transparent  to  the 
user.  The  objective  would  be  to  allow  the  user  to  access  the  ADR  database 
in  a  simple  straight  forward  manner.  These  functions  are  currently  not 
united  under  one  application.  Uniting  several  functions  under  one 
application  with  a  single  interface  allows  the  user  to  concentrate  on  the 
task  at  hand.  These  functions  should  be  implemented  in  a  manner  to 
minimize  the  load  on  the  host  machine  supporting  the  ADR  database. 

3)  Add  a  command  line  to  Boeing's  Sessions  Manager  software  as  an  option 
to  the  present  menu  structure.  Currently  all  users  must  step  through  a 
hierarchy  of  menus  to  reach  a  desired  command.  An  alternative 
command  line  would  allow  sophisticated  users  to  bypass  the  menus. 

4)  Develop  an  embedded  control  application  to  link  functions  through  a 
single  interface.  This  would  simplify  movement  between  applications, 
the  transfer  of  data  between  applications,  and  the  execution  of  common 
functions.  This  would  greatly  enhance  the  simplicity  from  the  user's 
perspective.  This  would  also  reduce  the  complexity  of  performing  a  task 
since  the  user  would  be  involved  with  only  one  application.  Figure  3.1 
compares  the  steps  necessary  to  complete  a  sample  task  using  the  present 
system  and  a  possible  control  application. 
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5)  Redesign  FIS  interfaces  to  allow  tasks  to  run  without  intermediate  user 
supervision.  Then  the  FIS  operator  could  input  all  parameters  necessary 
for  a  process  to  be  executed.  Once  these  parameters  were  entered,  the 
process  could  run  without  intermediate  user  supervision. 

6)  Use  an  integrated  package  for  the  word  processor,  database  management, 
spreadsheet  and  communications  software  functions  of  the  FIS.  This 
would  give  the  user  a  unified  interface  across  these  system  functions. 
Transferring  results  from  a  spreadsheet  to  a  word  processor  document  or 
to  a  database  would  be  easier  and  more  straightforward.  This  would  also 
reduce  training  time. 

7)  Utilize  the  marketing  clout  and  user  experience  of  HQ  FORSCOM  to 
influence  future  releases  of  the  off-the-shelf  PC  software  currently  used 
on  the  FIS:  dBase  III  Plus,  Lotus  1-2-3.  Multimate  Advantage,  etc.  FIS 
users  should  be  able  to  inform  the  software  vendor  of  desired  changes. 
This  would  improve  the  chance  that  future  off-the-self  software  would 
better  meet  FIS  needs.  This  would  also  lessen  the  probability  that 
upgrades  would  be  detrimental  to  the  FIS. 

3.1. 2.3  Training 

1)  Conduct  individual  task  training  based  on  the  actual  user  requirements 
of  specific  users.  FIS  users  have  received  adequate  general  instruction. 
However,  many  users  are  still  making  limited  use  of  their  systems. 
Training  that  focused  on  solving  a  particular  user’s  specific  job  problem 
would  more  likely  be  retained.  This  type  of  training  would  probably  be  a 
very  slow  process  designed  to  create  a  expanding  corps  of  computer-  and 
problem-competent  people.  A  strong,  well  supported  users  group  could 
greatly  facilitate  this  process.  Users,  not  just  user  representatives, 
should  be  encouraged  and  allowed  to  participate.  A  users’  group 
electronic  bulletin  board  would  be  effective  in  communicating  needs  and 
solutions.  The  creation  of  a  DSS  environment  and  eventually  individual 
DSS  will  also  simplify  training. 
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2)  Establish  task  response  teams  to  assist  user  task  accomplishment.  These 
task  response  teams  should  be  composed  of  a  cross  section  of  automation 
and  section  liaison/support  personnel  who  are  available  to  propose  and 
develop  solutions  for  specific  user  tasks.  They  would  analyze  the  user’s 
objectives;  and  propose  and  develop  the  best  automation  solution  given 
the  current  resources.  This  technioue  should  be  contrasted  with  the 
technique  of  responding  to  tactical  user  problems  and  then  proposing 
quick  fixes  that  do  not  take  into  account  the  user’s  broad  objectives. 

3.1.3  Recommended  Alternatives 

After  reviewing  the  list  of  available  alternatives  in  Section  3.1.2  the  following 
alternatives  were  selected  as  offering  the  best  chance  for  achieving  a  comparable 
functionality  and  establishing  a  foundation  for  future  DSS  development.  The 
selected  alternatives  are  logically  grouped  under  six  major  headings  as  listed  below: 

Baseline  Main  Frame 

•  Baseline  and  fine-tune  the  DOIM  IBM  4381  mainframe  host  processor. 
Enhance  Application  Interaction 

•  Develop  an  embedded  control  application  to  provide  a  set  of  common 
functions  through  a  single  interface. 

•  Redesign  some  FIS  interfaces  to  allow  tasks  to  run  without  intermediate 
user  supervision. 

Enhance  Sessions  Manager 

•  Enhance  Sessions  Manager  screens  to  decrease  steps  required  to  perform 
functions. 

•  Write  software  to  add  a  command  line  to  Boeing's  Sessions  Manager 
software. 
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Expand  Application  Software  Packages 


•  Write  software  to  expand  PC  Datacom  to  include  additional  data  retrieval 
and  graphical  display  functions. 

•  Acquire/develop  a  natural  language  interface  for  data  extraction. 

Task  Oriented  Training 

•  Conduct  individual  task  training  based  on  specific  user  requirements. 

•  Establish  task  response  teams  to  assist  users. 

Marketing  Clout 

•  Utilize  the  marketing  clout  and  user  experience  of  HQ  FORSCOM  to 
influence  future  releases  of  the  off-the-shelf  PC  software  currently  used 
on  the  FIS. 


3.1.4  Implementation  Guidelines 


The  six  major  recommendation  categories,  or  milestones,  are  displayed  in  the 
matrix  below.  Depicted  along  beside  each  recommendation  category  is  the  perceived 
priority  of  the  task,  the  estimated  time  to  accomplish  the  task,  and  the  tasks  that 
should  precede  each  individual  task: 

MILESTONES  MATRIX 


RECOMMENDATION  CATEGORY  TIME  PRIORITY 
S  Start  (Calender/months) 

1  Baseline  2  1 

2  Enhance  Application  Interaction  6  2 

3  Enhance  Sessions  Manager  3  3 

4  Expand  Application  Software  12  4 

5  Task  Oriented  Training  (Preparation)  3  5 

6  Marketing  Clout  1  6 

F  Finish 


PREDECESSORS 


none 

1 

none 

1,2 

2,3.4 

none 
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The  recommendations'  interrelationships  are  further  depicted  in  the  work  flow 
diagram  below: 

MILESTONE  WORK-FLOW  DIAGRAM 


The  Milestone  Work-Flow  Diagram  should  not  be  interpreted  too  rigidly.  The 
milestones’  interaction  and  precedence  may  overlap  or  run  in  parallel,  depending  on 
development  methodologies.  The  diagram  should  only  be  considered  as  a  general 
guide  for  precedence. 

The  completion  of  all  the  tasks  in  a  recommendation  category  should  be  treated  as 
the  completion  of  a  major  milestone  in  the  achievement  of  the  near  term  plan  for 
comparable  functionality  with  the  HQDA  DSS.  Accordingly,  the  completion  of  all 
the  recommendation  categories  would  result  in  the  achievement  of  the  basic 
functionality  of  the  HQDA  DSS. 


-28- 


3.2  FORSCOM  UN1QUK  ALTERNATIVKS 


3.2.1  CONUSA  Alternatives 

Given  the  situation  regarding  the  RCAS,  the  recommendation  for  the  short  term  is 
not  to  port  HQ  FORSCOM  applications  to  each  CONUSA,  but  to  provide  access  to 
the  system  via  remote  dial-in.  This  will  require  permission  from  the  program 
manager  for  RCAS  to  provide  network  access  to  the  FIS. 

3.2.2  Installation  Alternatives 

Installation  alternatives  relate  to  standardization  of  hardware  and  software.  These 
are  long  term  goals  and  they  are  discussed  in  Section  3.3,  Strategic  Plan. 

3.2.3  Mainframe/ Workstation  Utilization 

HQ  FORSCOM  has  several  options  in  determining  the  best  way  to  exploit  the 
computing  power  that  exists  on  site: 

1)  the  host/distributed  processors  can  be  used  for  data  and  graphics 
manipulation  and  display, 

2)  small  functional  databases  and  support  modules  (including  graphics)  to 
allow  most  work  to  be  done  on  the  workstations,  or 

3)  portions  of  the  Command  Data  Base  could  be  downloaded  to  the 
workstation  for  data  and  graphics  manipulation. 

There  are  advantages  and  disadvantages  to  each,  which  will  be  addressed 
separately. 

3.2.3.1  Use  of  Host/Distributed  Processors 

HQDA  DSS  is  implemented  on  a  single  mainframe,  while  the  FIS  has  multiple 
mainframes  that  can  be  used.  Using  the  FIS  host  or  distributed  processors  to  store, 
manipulate,  and  display  data  provides  a  simple  method  of  creating  a  comparable 
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DSS.  This  would  provide  a  configuration  closest  to  that  of  the  HQDA  DSS.  If  a  user 
is  updating  a  data  set,  other  users  are  prevented  from  trying  to  update  the  same 
data.  This  helps  prevent  data  corruption.  There  is  little  chance  of  having  multiple 
versions  of  data  on  the  system  simultaneously.  The  mainframes  have  sufficient 
power  to  support  many  users  without  difficulty.  In  addition,  since  only  the 
mainframe  is  used  (the  workstation  acts  as  a  dumb  terminal),  the  user  only  needs  to 
learn  one  system. 

There  are  drawbacks  to  the  host/distributed  processor  approach.  While  this 
configuration  would  be  the  closest  to  that  at  HQDA,  it  is  not  necessarily  the  best  for 
HQ  FORSCOM.  Mainframe  software  tends  to  be  more  cumbersome  and  harder  to 
use  than  PC  software  when  performing  comparable  functions.  The  FIS  host  system 
would  slow  down  as  more  users  accessed  the  database,  and  the  full  potential  of  the 
workstations  would  not  be  realized.  As  a  result,  HQ  FORSCOM  would  have  to  add 
more  resources,  or  rearrange  existing  ones.  Additionally,  depending  on  the  system 
load,  users  would  have  variable  response  times.  The  response  time  would  often  be 
too  long  for  the  user  to  wait.  Also,  if  the  host  system  goes  down,  the  user  cannot 
accomplish  the  assigned  task.  Using  the  workstation  to  do  some  or  all  the  work 
would  alleviate  load  problems.  If  a  workstation  goes  down,  only  the  single  user  is 
affected. 

Overall,  the  host/distributed  processor  approach  could  turn  out  to  be  the  most  costly 
solution.  Since  the  money  has  been  spent  on  the  workstations,  FORSCOM  should 
take  advantage  of  this  desktop,  power.  As  technology  progresses,  upgrading  the 
workstations  will  be  much  simpler  and  cheaper  that  upgrading  mainframe 
computers.  At  the  current  rate  of  technological  advancement  the  workstation 
capacity  will  soon  reach  that  of  today's  mainframe  computer. 

3.2.3.2  Small  Functional  Databases 

Using  the  workstations  to  store,  manipulate,  and  display  the  data  is  a  second 
alternative.  This  utilizes  the  full  potential  of  the  workstation,  freeing  the  user  from 
problems  of  the  mainframe  computers.  The  number  of  users  manipu.  ating  data  does 
not  affect  response  time;  the  time  needed  for  any  given  calculation  will  be  the  same 
every  time.  If  a  system  goes  down,  the  user  can  simply  move  to  another  machine. 
The  mainframe  computers  can  be  used  for  electronic  mail  and  to  transfer  data  among 


-30 


installations  or  users  on  site.  Given  the  rapid  development  of  PC  technology  users 
will  be  able  to  gain  significant  improvements  near  term  through  upgrades  to  the 
workstation.  Additionally,  workstation  applications  can  be  made  very  user  friendly, 
which  is  more  difficult  for  mainframe  software.  Since  the  mainframe  is  not  used,  the 
user  need  only  be  knowledgeable  about  the  workstation. 

There  are  drawbacks  to  this  solution  as  well.  Now,  instead  of  under-utilizing  the 
workstations,  as  in  the  first  alternative,  the  mainframe  computer  is  under  utilized. 
In  addition,  multiple  users  will  often  need  to  deal  with  the  same  data.  Letting  each 
workstation  have  its  own  database  would  almost  guarantee  having  multiple, 
different  copies  of  the  same  data  set.  Without  strict  data  control,  there  would  be 
chaos.  Some  users  may  have  to  deal  with  data  sets  that  are  too  large  for  the 
standard  workstation,  or  the  manipulation  may  be  too  complex  for  the  workstation 
to  do  in  a  reasonable  time. 

G.2.3.3  Downloading  Portions  of  the  CDB 

Using  the  mainframe  computer  to  store  the  data,  while  data  manipulation  and 
display  take  place  on  the  workstation  provides  an  intermediate  alternative.  Both 
mainframe  and  workstation  computers  are  utilized.  The  user  does  not  have  to  worry 
as  much  about  the  mainframe  going  down,  since  a  portion  of  the  database  will 
already  be  on  the  workstation.  If  the  workstation  goes  down,  the  user  can  transfer 
the  small  database  to  another  workstation.  If  the  user  must  deal  with  large  data  sets 
or  very  complex  data  manipulation,  the  capability  should  exist  for  the  user  to  access 
the  mainframe  to  do  the  task.  Computer  response  time  will  remain  stable.  Modified 
data  is  uploaded  to  the  mainframe  system,  so  that  other  users  will  be  able  to  access 
this  updated  information.  As  mentioned  previously,  workstation  applications  can  be 
made  very  user  friendly,  which  is  more  difficult  for  mainframe  software. 

There  are  drawbacks  to  this  solution  as  well.  It  is  still  probable  that  multiple  users 
will  need  to  access  and  manipulate  the  same  data.  Proper  data  administration  is 
required  to  ensure  date  integrity.  Additionally,  since  both  computer  systems  are 
used,  the  user  will  need  to  be  familiar  with  the  workstation  application  and  know 
how  to  upload  and  download  data. 
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3. 2.3.4  Summary 


Under  alternative  one,  the  host/distributed  processors  can  be  used  for  data  and 
graphics  manipulation  and  display.  Alternative  two  incorporates  small  functional 
databases  and  support  modules  (including  graphics)  to  allow  most  work  to  be  done  on 
the  workstations.  Alternative  three  allows  portions  of  the  Command  Data  Base 
could  be  downloaded  to  the  workstation  for  data  and  graphics  manipulation. 

The  possibility  of  data  corruption  is  greatest  under  alternative  one.  Alternative  two 
provides  the  best  data  safety. 

The  best  distribution  of  work  is  provided  by  alternative  three  sharing  work  between 
the  workstations  and  mainframe  computers.  Alternatives  one  and  two  do  not 
distribute  work  properly. 

Alternative  two  provides  independence  from  mainframe  failures.  Alternative  three 
alleviates  part  of  the  problem.  Total  dependence  on  the  mainframe,  as  in  alternative 
one,  can  result  in  massive  delays  and  uncompleted  tasks  due  to  system  failure. 

In  terms  of  easy-to-use  applications,  either  of  the  alternatives  employing  the 
workstation  to  manipulate  the  data  is  preferable  to  using  the  mainframe. 

Since  the  second  alternative  accesses  both  systems,  the  user  must  have  at  least 
minimal  knowledge  of  both  the  mainframe  and  workstation  computers.  The  other 
alternatives  only  require  knowledge  of  one  system. 

In  general,  the  third  alternative  (downloading  portions  of  the  database)  would  have 
to  be  given  a  higher  rating.  The  potential  for  user-friendly  operation  will  minimize 
training  time.  The  requirement  of  having  knowledge  of  both  systems  can  be 
minimized  with  user-friendly  software  on  the  workstation.  Insulation  from 
mainframe  problems  also  saves  the  user  from  either  not  getting  the  job  done  or 
having  to  kill  time  until  work  can  be  finished.  Advancements  in  PC  software  and 
hardware  are  certain  to  provide  capabilities  equal  or  superior  to  today's  mainframes 
in  the  near  future.  The  other  alternatives  would  rate  about  even. 
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3.3  STRATEGIC  PLANNING  GUIDANCE 


FORSCOM  needs  a  strategic  plan  to  provide  direction  and  guidance  for 
implementation  of  DSS  throughout  the  command.  Command  goals  and  strategic- 
planning  exist  for  many  of  the  system  components  as  described  in  Section  2.2.  A 
plan  is  needed  that  consolidates  existing  guidance  with  a  focus  on  creation  of  a  DSS 
development  environment  and  addresses  the  technologies  supporting  the  FORSCOM 
mission.  The  plan  should  cover  a  period  of  for  five  to  eight  years  into  the  future. 
This  section  provides  general  and  specific  guidance  for  creation  of  that  plan. 

3.3.1  Strategic  Objectives  for  DSS  Implementation 

These  strategic  objectives  for  the  FORSCOM  DSS  study  are  derived  from  the 
following  sources. 

1)  The  implied  objectives  based  on  the  task  descriptions  from  the  FORSCOM 
DSS  Study  Statement  of  Work. 

2)  A  comparison  between  the  environments  at  HQDA  and  at  HQ 
FORSCOM. 

3)  Assessment  of  the  impact  on  FORSCOM  of  other  DSS  efforts  initiated  by 
other  MACOMs  or  Army  agencies. 

GTRI  proposes  three  objectives  for  implementation  of  Decision  Support  Systems  at 
HQ  FORSCOM. 

1)  Implement  integrated  DSS  throughout  the  headquarters  to  provide 
application  specific  capabilities  to  action  officers  and  senior  management. 

2)  Provide  for  utilization  of  distributed  databases  within  FORSCOM  and  the 
rest  of  the  Army  and  DOD. 

3)  Initiate  a  long  term  strategy  which  provides  for  exporting  FORSCOM 
developed  DSS  software  to  subordinate  installations  and  other- 
commands:  and  importing  DSS  developed  outside  of  FORSCOM. 
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3.3.2  Recommended  Alternatives  Planning 

The  recommended  alternatives  for  Strategic  Planning  are  discussed  with  regard  to 
the  objectives  from  Section  3.1.1  and  are  organized  accordingly.  GTRI  recommends 
these  alternatives  to  the  FORSCOM  planning. 

3.3.2.1  Alternatives  for  DSS  Implementation 

1)  Write  a  Strategic  Plan. 

This  plan  should  include  an  assessment  of  the  current  state  of  Decision 
Support  Systems  and  automation  at  Headquarters  FORSCOM,  an 
assessment  of  mission  supporting  technologies  projected  for  the  future, 
and  an  assessment  of  Army-wide  automation  efforts  for  compatibility. 

2)  Obtain  Command  Sponsorship. 

The  FORSCOM  Commander  is  the  ultimate  decision  maker  who  must  be 
supported  by  the  FORSCOM  DSS.  He  should  be  an  integral  part  of  the 
DSS  planning  process,  and  be  constantly  appraised  of  the  implementation 
progress. 

3)  Use  an  Established  DSS  Development  Methodology. 

Experience  with  implementation  of  Decision  Support  Systems  has 
demonstrated  that  trying  to  plan  and  implement  an  all-encompasing  DSS 
for  an  organization  does  not  work.  Information  and  decision  support 
systems  should  not  be  developed  like  weapons  systems.  By  the  time  all 
the  requirements  are  captured  and  the  design  is  agreed  upon,  the 
technologies  and  requirements  upon  which  the  DSS  is  based  have 
changed  and  the  system  is  doomed  for  expensive  obsolescence.  A  less 
costly  alternative  with  a  proven  success  rate,  is  to  incrementally  develop 
software  and  expand  the  system  as  requirements  and  technology  evolve. 
A  local  success  story  is  the  MICROFIX  system  built  for  FORSCOM  J2  by 
GTRI.  A  Use-Learn-Develop  design  philosophy  was  adopted  for  that 
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program.  It  recognized  that  all  system  requirements  cannot  be  easily 
specified  at  the  beginning,  in  sufficient  detail,  for  software  development 
to  be  successful.  This  philosophy  also  provided  system  availability  at  an 
early  stage  of  development.  The  developers  were  allowed  to  refine  and 
add  to  the  system  as  experience  and  specific  requirements  dictated. 


A  similar  approach  to  the  incremental  and  "Use-Learn-Develop” 
methodologies  has  been  adopted  by  HQDA.  This  approach  is  summarized 
in  the  HQDA  DSS  Master  Plan  as  follows: 

Our  studies  and  our  experience  demonstrate  that 
grandiose,  highly  centralized  planning  of  decision  systems- 
systems  designed  to  be  all  things  to  all  users— almost 
always  fail.  The  "ink  blot”  approach,  characterized  by  the 
use  of  a  conceptual  architecture,  high  level  design,  and  an 
aggressive  yet  flexible  development  process,  significantly 
increases  the  probability  of  success.  Using  this  approach, 
components  of  the  overall  plan  (the  ink  blots)  can  be 
developed  rapidly  and  independently-consistent  with  the 
architecture  and  design  for  the  whole.  Over  time,  as  more 
components  are  developed,  new  ink  blots  are  added  and/or 
earlier  ink  blots  are  expanded-extending  DSS  capabilities 
in  an  integrated  manner.  This  concept  is  a  keystone  within 
the  HQDA  DSS  vision.  It  is  guidance  by  a  proven  template 
of  success,  cloning  success  from  one  system  initiative  to 
another.  It  requires  a  conceptual  framework  within  which 
the  "ink  blots”  can  grow  with  assurance  of  ultimate 
integration. 


The  philosophies  of  "incremental  development”,  "Use-Learn-Develop”, 
and  "Ink  Blot”  show  a  common  theme  that  is  recommended  for  DSS 
implementation  in  FORSCOM. 


4)  Organize  a  DSS  Development  Environment. 

A  system  concept  and  DSS  development  environment  will  be  needed  to 
control  system  management  and  life  cycle  costs.  It  is  conceivable  that 
FORSCOM  could  have  each  DSS  with  different  development  languages, 
different  user  interfaces,  different  in-line  documentation  standards.  This 
could  create  serious  problems  with  management,  maintenance,  and  life 
cycle  cost. 
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GTRI  recommends  that  FORSCOM  specify  responsibilities  for  a  FORSCOM 
DSS  development  environment.  FORSCOM  has  a  unique  mission  and 
physical  environment,  and  the  organizational  model  appropriate  to  another 
agency,  such  as  HQDA,  should  not  be  imposed  on  FORSCOM.  A  better 
approach  would  be  to  learn  from  the  HQDA  experience  (and  other  agencies) 
and  adopt  applicable  ideas  and  practices  to  the  FORSCOM  environment.  The 
general  recommendation  is  that  each  joint  directorate  within  HQ  FORSCOM 
be  made  responsible  for  the  following : 

•  Define  DSS  requirements 

•  Plan  DSS  implementation 

•  Develop  applications 

•  Monitor  contracts 

•  Maintain  applications’ software 

•  Provide  applications’  software  training 

Any  DSS  applications  generated  at  FORSCOM  would  be  built  in  accordance 
with  guidance  provided  by  a  designated  office  or  function.  That  office  would  be 
responsible  for  ensuring  the  DSS  development  environment  is  established,  and 
it  will  retain  general  functional  responsibility.  That  office  might  include  such 
things  as: 


•  Plans  and  Architecture 

•  Systems  Engineering 

•  Training 

•  Database  Administration 

•  Development  of  Standards 

•  Contractor  Guidances 

•  Systems  Security 

•  Computer  Operations 

These  functions  are  of  course  already  being  performed  at  FORSCOM.  This 
plan  does  not  suggest  any  organizational  changes,  rather  it  suggests  an 
organizational  focus  that  would  provide  u  DSS  development  environment  to 
achieve  comparable  capability  with  the  HQDA  DSS. 
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5)  Set  DSS  Development  Standards. 

The  FORSCOM  DSS  development  environment  will  include  the 
standards  that  control  the  software  development  process.  A  sample  list  of 
areas  to  provide  guidance  follows: 

•  User  interface  standards 

•  Documentation  requirements  and  standards 

•  Configuration  management  standards  and  procedures 

•  Database  management  standards 

•  Systems  security  procedures 

•  Software  development  guidances 

•  Standard  programming  language(s) 

6)  Test  the  Environment  by  Building  a  DSS. 

The  DSS  environment  can  best  be  demonstrated  and  tested  by  building  a 
DSS  in  accordance  with  the  guidance  and  direction  developed  under  the 
previous  recommendations.  Two  examples  of  specific  candidates  for  DSS 
development  with  regard  to  the  budget  functions  in  FORSCOM  are 
contained  in  Appendix  A  to  this  Study. 

7)  Implement  Other  DSS  as  Requirements  are  Generated  and  as  Resources 
are  Made  Available. 

A  detailed  grand  plan  for  each  DSS  to  be  implemented  at  FORSCOM  is 
not  required.  DSS  can  be  implemented  as  functional  DSS  user 
requirements  are  formulated,  and  as  time  and  funding  permit.  DSS 
requirements  in  the  J8,  for  example,  could  flow  to  a  candidate  DSS 
description  (similar  to  the  examples  in  Appendix  A).  HQ  Forces  Comand 
Functions  Manual  (reference  10)  could  serve  as  a  top  level  cross  reference 
for  structuring  candidate  DSS.  Data  flows  and  relations  can  be  obtained 
using  the  Information  Architecture  Model,  (reference  11)  to  provide 
design  specific  information.  A  process  to  follow  for  requirements 
definition  and  DSS  design  is  contained  in  reference  5.  Guide  for  DSS 
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Development.  That  document  also  contains  helpful  information 
regarding  all  aspects  of  DSS  development. 


3.3.2.2  Alternatives  for  Distributed  Databases 

A  technological  trend  within  industry  and  DOD  is  toward  the  use  of  distributed 
databases.  Distributed  databases  allow  for  capturing  the  data  at  the  source  with 
single  agency  responsibility  for  updating  and  maintaining  data.  On-line  or 
distributed  access  to  the  database  at  the  source  insures  currency  and  prevents 
different  versions  of  the  same  data  from  entering  the  decision  process. 

1)  Implement  distributed  database  with  FORSCOM  installations;  two 
methods  are  available. 

•  Distribute  database  -  no  duplication 

The  installation  becomes  the  sole  possessor  of  the  data.  Any 
installation  data  required  by  HQ  FORSCOM  is  done  via  remote 
query. 

•  Distribute  database  -  with  duplication 

The  installation  is  the  proponent  of  the  data,  but  HQ  FORSCOM 
keeps  a  copy  locally.  The  installation  periodically  updates  HQ 
FORSCOM  database.  This  allows  HQ  FORSCOM  to  view  data  and 
make  decisions  even  if  the  installation  computer  or  network  link 
fails.  The  installation  database  is  the  master. 

2)  Piggyback  other  Army  and  DOD  initiative  for  distributed  databases. 

Set  responsibility  within  FORSCOM  to  monitor  outside  initiatives  for 
distributed  databases.  As  these  initiatives  are  successful  in  providing 
data  of  use  to  FORSCOM,  implementation  at  FORSCOM  should  be 
initiated. 
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3)  Utilize  standard  database  interface. 

Portability  of  applications  software  will  be  greatly  enhanced  by  use  of  a 
standard  database  interface.  The  standard  interface  allows  the 
application  to  address  the  supporting  data  through  the  interface  without 
regard  to  the  exact  location  or  specifics  of  the  underlying  database.  The 
application  should  be  separated  from  the  data  via  a  standard  interface. 

SQL  has  become  the  defacto  standard  for  much  of  the  industry  including 
HQDA.  Use  of  SQL  at  the  installations  would  facilitate  movement  of 
applications  software . 

4)  Use  PCs. 

The  use  of  PCs  is  not  standard  at  the  installations.  Some  installations  use 
PCs  as  local  workstation/terminals  similar  to  the  FIS,  while  other 
installations  do  not.  Utilizing  PCs  and  defining  standard  PC  software  (as 
done  in  the  FIS)  would  allow  easier  transfer  of  software  from  HQ 
FORSCOM  to  installation.  This  includes  contractor-developed  software 
in  addition  to  application  tools  developed  by  FIS  or  installation  users. 
Using  PCs  as  terminals  also  simplifies  procurement,  training  and 
maintenance  once  existing  terminals  are  be  phased  out. 


3.3.2.3  Alternatives  for  Import /Export  of  Software 
1)  Standardize  operating  systems. 

Even  though  the  hardware  at  the  installation  level  standardized  on  the 
IBM  43xx  series  computer,  the  operating  systems  in  use  cover  the 
spectrum.  The  MVS,  VM  and  DOS/VSE  operating  systems  are  scattered 
throughout  the  installations. 

Standardization  on  a  single  operating  system  at  the  installation  level 
would  enable  HQ  FORSCOM  and  the  installations  to  utilize  virtually  any 
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software  developed  for  a  single  site.  Distribution  of  data  and  electronic 
mail  would  be  simpler.  This  standardization  would  be  expensive  to  do  at 
one  time.  Therefore  doing  it  as  part  of  the  normal  upgrade  and 
replacement  life-cycle  would  be  the  most  effective  method.  Any 
installations  changing  operating  systems  would  potentially  lose 
applications  that  would  not  port  to  a  new  operating  system.  Therefore, 
careful  consideration  of  individual  cost/benefit  is  needed. 

2)  Set  software  standards. 

FORSCOM  should  standardize  the  software  in  use  throughout  the  FIS 
and  the  installations  a  much  as  possible.  Common  software  at  HQ 
FORSCOM  and  the  installations  would  facilitate  maintenance,  data 
transfer  and  the  training  of  users.  This  software  would  include  individual 
DSS  in  addition  to  utilities  such  as  Lotus  1-2-3.  Standards  should  be 
flexible  to  prevent  some  sites  from  having  to  discard  a  large  number  of 
programs.  FORSCOM  has  initiated  some  standardization  at  the  HQ  level 
by  defining  a  standard  set  of  software  on  the  PC.  This  process  should  be 
continued  at  the  installation  level.  When  developing  or  purchasing 
software,  insure  that  the  FIS  system  tracks  as  much  as  possible  with 
standards. 


4.0  CONCLUSION 

HQ  FORSCOM  can  achieve  comparable  functionality  with  the  DSS  capabilities  at 
HQDA  by  implementation  of  the  near  term  and  strategic  planning  guidance 
provided  in  this  study.  As  those  DSS  capabilities  are  implemented,  FORSCOM 
action  officers  and  senior  staff  will  be  able  to  make  faster  and  better  decisions.  These 
enhanced  capabilities  will  dramatically  improve  decision  support  at  FORSCOM  and 
have  a  beneficial  effect  on  all  aspects  of  its  mission. 

The  maximum  immediate  payoff  for  HQ  FORSCOM  with  regard  to  Decision  Support 
Systems  will  be  to  implement  the  recommendations  from  the  near  term  plan.  These 
are:  baseline  the  mainframe,  enhance  application  interactions  of  commercial 
software  packages,  enhance  Sessions  Manager  for  added  functionality,  expand 
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applications  software,  provide  task-oriented  training,  and  exercise  marketing  clout 
to  influence  commercial  software  modifications. 

A  strategic  plan  would  provide  a  low  cost  road  map  for  DSS  implementation  for 
FORSCOM  and  provide  DSS  connectivity  with  other  Army  agencies.  The  strategic- 
plan  should  then  be  tested  by  building  an  initial  DSS  followed  by  other  DSS  as 
requirements  evolve  and  funding  is  available. 


Appendix  A 

FORSCOM  I)SS  STUDY 


Sample  DSS  for  the  FORSCOM  Budget  Process 

The  budget  process  within  the  FORSCOM  Resource  Management  Directorate  served 
as  the  focal  point  for  all  detailed  analysis  conducted  in  the  FORSCOM  DSS  Study. 
The  rationale  behind  use  of  that  specific  function  is  contained  in  paragraph  1.1  of  the 
study.  This  appendix  provides  a  brief  overview  of  the  budget  process  and  two  sample 
decision  support  system  descriptions  specific  to  that  process. 

Figure  A-l  depicts  data  and  information  flows  affecting  the  FORSCOM  budget 
process.  Guidance  and  decision  affecting  the  FORSCOM  budget  are  input  from  DA. 
HQ  FORSCOM  in  turn  provides  budget  guidance  to  its  subordinate  installations. 
The  installations  provide  HQ  FORSCOM  with  actual  budgets  and  execution  plans. 
Funding  authorization  and  execution  data  are  handled  through  USAFAC  who 
provides  execution  data  back  to  HQ  FORSCOM  and  DA.  Excution  data  is  also 
provided  directly  back  to  HQ  FORSCOM  by  each  funded  installation.  The  heart  of 
the  system  is  the  FAPABS  as  described  in  the  FORSCOM  Automated  Program  and 
Budget  System  (FAPABS)  Functional  Users  Manual,  Draft  (reference  8). 

Suggestions  for  system  enhancements  and  functionality  comparisons  of  the  FAPABS 
to  the  BMIS  system  at  HQDA  QDCSLOG  have  been  proposed  by  FORSCOM  J8 
personnel.  Reference  7  contains  functionality  comparisons  made  by  Mr.  Bobby 
Bryant  in  a  memorandum.  Additional  functionality  comparisons  and  suggestions 
were  made  in  Section  2.0  of  the  FORSCOM  DSS  Study. 

In  cooperation  with  FORSCOM  J8  personnel  additional  ideas  for  decision  support 
systems  applicable  to  the  FORSCOM  budget  process  were  discussed.  Two  of  those 
ideas  are  described  as  candidate  DSS  and  are  included  in  this  appendix  as  examples. 
These  candidate  DSS  are  referred  to  as  modules  in  the  description.  A  goal  would  be  a 
total  resource  management  system  made  up  of  several  functional  modules. 
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FORSCOM  BUDGET  PROCESS 


STANFINS 
EXECUTION  DATA 


TITLE:  FORSCOM  AUTOMATED  PROGRAM  BUDGET  SYSTEM  UPGRADE 


DESCRIPTION:  This  module  would  "humanize”  the  current  FAPABS  system  as  it 
exists  in  the  FORSCOM  headquarters. 

APPLICATION:  The  data  in  FAPABS  contains  programmed  data  for  dollars  and 
manpower  for  all  appropriations  managed  by  J8  and  also  sub-managed  by  the 
various  program  directors.  For  example,  many  of  the  Program  2  funds  are  managed 
by  the  J3  who  is  the  proponent  for  operations.  All  resource  managers  need  to  be  able 
to  extract  current  dollar  and  manpower  guidance  from  the  command  data  base  and 
to  show  this  data  using  graphics  packages. 

INFORMATION  NEEDED:  Current  program/budget  data  from  Department  of  the 
Army  is  required  as  the  baseline  for  the  FAPABS  database.  This  data  is  normally 
organized  by  showing  direct  dollar  amounts  by  AMS  and  by  MDEP  (Management 
Decision  Package)  and  by  Issue  Codes.  Program  Objective  Memorandum  data  would 
be  available  for  all  out-  years.  Execution  data  from  installations  should  be  tied  into 
the  database  to  allow  budget  analysts  to  compare  obligations  against  outlays 
between  fiscal  years.  Unit  Status  Report  data  would  be  available  and  would  be 
compared  to  the  current  funding  available  to  the  installation. 

INFORMATION  GENERATED:  The  system  would  generate  spreadsheet  reports 
showing  how  funds  are  distributed  to  the  FORSCOM  installations.  Graphics  would 
show  fund  breakout  by  appropriation  and  by  major  program  and  would  allow 
immediate  comparisons  between  installations.  Major  program  managers  would  be 
able  to  make  dollar  distribution  within  this  system  (distribute  or  withhold). 
Mathematical  formulas  would  calculate  reductions  in  readiness  based  on  reductions 
in  funding.  Managers  would  be  able  to  analyze  the  adds  and  drops  (audit  trail)  for 
changes  in  dollar  and  manpower  amounts  tied  to  a  given  MDEP. 

DEVELOPMENTAL  RISK: 

TECHNICAL  RISK:  Medium  risk. 

DATA:  The  data  is  readily  available  across  several  standard  Army  systems.  The 
comparison  for  funding  versus  the  effort  on  readiness  would  be  more  difficult  to 
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obtain.  If  the  model  used  is  perceived  as  inadequate  by  the  users,  it  will  fall  in  to 
immediate  disuse. 

DEVELOPMENTAL  EFFORT:  Medium  risk  based  on  the  formula  that  would 
have  to  be  developed  in  the  readiness/funding  comparison. 

BENEFIT  RISK:  The  data  is  available  in  several  standard  Army  systems  but  is 
very  difficult  for  action  officers  and  decision  makers  to  put  together  in  one  place.  A 
Natural  Language  Interface  package  would  make  it  much  easier  for  an  action  officer 
to  extract  FAPABS  data.  The  time  saved  would  be  considerable. 


TITLE:  FORSCOM  AUTOMATED  UNFINANCED  REQUIREMENTS  SYSTEMS 


DESCRIPTION:  This  module  will  assist  decision  makers  in  determining  what 
unfinanced  requirements  (UFRs)  exist  at  the  installation  level  and  what  the  effect  is 
when  additional  funding  becomes  available  to  satisfy  these  UFRs. 

APPLICATION:  This  module  could  be  used  by  the  Director  of  Resource 
Management;  his  deputy;  the  Chief,  Program  Budget  Division;  the  Chief,  Active 
Component  Branch,  the  Chief,  Installation  Analysts  and  his  subordinate  budget 
analysts,  and  Chief,  Reserve  Component  Branch.  The  system  could  be  mad  • 
available  to  resource  managers  in  each  FORSCOM  staff  directorate  and  to  the 
individual  installations. 

INFORMATION  NEEDED:  Required  from  the  installation  resource  manager  is  the 
title  of  the  UFR,  the  total  dollar  amount,  installation  priority  assignment,  the  AMS 
(Army  Management  Structure)  codes  and  MDEP  (Management  Decision  Package) 
code  where  applicable,  and  an  impact  statement  of  at  least  500  words  length  on  the 
effect  on  mission  performance  if  the  UFR  is  not  funded.  This  UFR  system  exists 
currently  as  a  stand-alone  PC-based  system  used  by  installations.  The  system 
produces  dBase  III  database  files  which  are  aggregated  at  FORSCOM  level. 
FORSCOM  Program  Budget  Guidance  is  required.  It  is  currently  available  only  as  a 
written  document.  Dollar  guidance  for  total  obligation  authority  is  available  to  all 
FORSCOM  Information  System  users  through  FAPABS. 

INFORMATION  GENERATED:  The  module  would  provide  the  decision  makers  at 
each  level  with  the  capability  to  list  the  unfinanced  requirements  for  a  given 
FORSCOM-funded  installation  and  to  obtain  detailed  information  in  the  UFR. 
Installations  would  access  the  UFR  system  by  modem  and  would  enter  the  UFR 
information  using  a  standard  screen  report  format.  This  would  allow  installation 
resource  managers  to  continually  update  their  UFR  lists.  For  example,  a  UFR  can 
consist  of  several  different  AMS  codes,  and  can  show  how  the  money  in  each  AMS 
code  would  be  spent  by  Element  of  Resource  (EOR).  The  dollar  information  would 
then  be  used  to  determine  the  effect  of  additional  funding  when  it  is  made  available 
to  the  installation.  The  module  would  list  for  the  decision  maker  which  UFRs  would 
be  satisfied  by  priority  with  a  given  amount  of  money.  The  module  would  allow  the 
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decision  maker  to  "what  if’  the  spread  of  additional  funding  across  some  or  all  of  the 
FORSCOM-funded  installations  until  an  acceptable  mix  is  obtained.  The  module 
could  also  provide  to  the  decision  maker  a  graphics  capability  showing  total  UFR 
amounts  versus  the  amount  of  UFRs  actually  funded  during  the  fiscal  year. 

DEVELOPMENTAL  RISK:  Low  risk. 

DATA:  The  data  is  already  compiled  in  PC-based  applications  and  would  be 
easily  adapted  to  a  mainframe  application. 

DEVELOPMENTAL  EFFORT:  Low  risk.  The  calculations  used  to  arrive  at 
decisions  are  very  straightforward.  It  is  simply  balancing  needs  against 
available  funding. 

BENEFIT  RISK:  The  data  is  currently  available  in  a  PC-based  standalone 
application.  It  would  save  a  great  deal  of  time  at  the  installation  level  because  users 
would  be  able  to  enter  UFRs  directly  into  the  corporate  UFR  database.  The  time 
spent  developing  and  refining  dBase  III  applications,  particularly  when  changes 
occur  in  PC  software,  would  be  saved.  The  process  used  by  installation  analysts  in 
obtaining  the  data  from  the  standalone  program  requires  them  to  wait  on  the 
processing  to  diskettes  created  for  each  installation  analyst  and  this  process  is 
cumbersome  and  time  -  consuming.  UFR  data  cannot  be  readily  charted  based  on 
current  information  unless  the  data  is  taken  from  a  printout  and  physically  placed 
into  a  graphics  package  such  as  Microsoft  Windows,  Harvard  Graphics,  or  Lotus 
Freelance.  UFR  data  is  not  readily  available  to  major  decision  makers  except  as 
printouts. 
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